Network traffic shaping for low power and lossy networks

ABSTRACT

In one embodiment, data packet messages are received in a Field Area Router (FAR) sent from one or more sources toward one or more destination devices in a Low-Power Lossy Network (LLN). An LLN routing topology for the data packet messages is interpolated in the FAR. An expected time for the data packet messages to reach a destination device in the LLN is determined based upon the routing topology interpolation. Traffic shaping is applied by the FAR for the data packet messages based upon the determined expected time for the data packet messages to reach destination devices in the LLN.

RELATED APPLICATION

The present application is a Continuation Application of U.S. patentapplication Ser. No. 13/653,084, filed Oct. 16, 2012, entitled NETWORKTRAFFIC SHAPING FOR LOW POWER AND LOSSY NETWORKS, by Jonathan W. Hui etal., the contents of which is hereby incorporated by reference

TECHNICAL FIELD

The present disclosure relates generally to computer networks, and, moreparticularly, to mechanisms for shaping network traffic flow.

BACKGROUND

Low power and Lossy Networks (LLNs), e.g., sensor networks, have amyriad of applications, such as Smart Grid and Smart Cities. Variouschallenges are presented with LLNs, such as lossy links, low bandwidth,battery operation, low memory and/or processing capability, etc. Oneexample routing solution to LLN challenges is a protocol called RoutingProtocol for LLNs or “RPL,” which is a distance vector routing protocolthat builds a Destination Oriented Directed Acyclic Graph (DODAG) inaddition to a set of features to bound control traffic, support local(and slow) repair, etc. The RPL routing protocol provides a flexiblemethod by which each node performs DODAG discovery, construction, andmaintenance.

One problem that confronts LLNs is communication challenges. Forinstance, LLNs communicate over a physical medium that is stronglyaffected by environmental conditions that change over time. Someexamples include temporal changes in interference (e.g. other wirelessnetworks or electrical appliances), physical obstruction (e.g. doorsopening/closing or seasonal changes in foliage density of trees), andpropagation characteristics of the physical media (e.g. temperature orhumidity changes). The time scales of such temporal changes can rangebetween milliseconds (e.g. transmissions from other transceivers) tomonths (e.g. seasonal changes of outdoor environment). Additionally,low-cost and low-power designs limit the capabilities of LLNtransceivers. In particular, LLN transceivers typically provide lowthroughput. Furthermore, LLN transceivers typically support limited linkmargin, making the effects of interference and environmental changesvisible to link and network protocols.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein may be better understood by referring to thefollowing description in conjunction with the accompanying drawings inwhich like reference numerals indicate identically or functionallysimilar elements, of which:

FIG. 1 illustrates an example computer network and a directed acyclicgraph (DAG);

FIG. 2 illustrates an example network device/node;

FIG. 3 illustrates an example message;

FIGS. 4 and 5 illustrates example networks coupled to a Field AreaRouter;

FIGS. 6 and 7 illustrate example simplified procedures for routing datapacket messages with traffic shaping techniques according to certainillustrated embodiments.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

According to one or more embodiments, data packet messages are receivedin a Field Area Router (FAR) sent from one or more sources toward one ormore destination devices in a Low-Power Lossy Network (LLN). An LLNrouting topology for the data packet messages is interpolated in theFAR. An expected time for the data packet messages to reach adestination device in the LLN is determined based upon the routingtopology interpolation. Traffic shaping is applied by the FAR for thedata packet messages based upon the determined expected time for thedata packet messages to reach destination devices in the LLN.

In another embodiment, data packet messages are received in a FAR devicefrom a LLN. An LLN routing topology for the data packet messages isinterpolated in the FAR. An approximate number of data packet messagesthe FAR is to receive from the LLN is determined. Traffic shaping isapplied by the FAR for the data packet messages transmitting in the LLNto be received by the FAR based upon the determined number of datapacket messages the FAR is to receive from the LLN.

In yet another embodiment, multicast data packet messages to beforwarded to a LLN are received in a FAR. An LLN routing topology forthe multicast data packet messages is interpolated in the FAR. Trafficshaping is applied by the FAR for the multicast data packet messages bymodeling the time it takes for a data packet message to propagate acrossa prescribed amount of nodal hops in the LLN prior to the FAR initiatingsubsequent transmission of multicast data packet messages in the LLN.

DESCRIPTION

A computer network is a geographically distributed collection of nodesinterconnected by communication links and segments for transporting databetween end nodes, such as personal computers and workstations, or otherdevices, such as sensors, etc. Many types of networks are available,with the types ranging from local area networks (LANs) to wide areanetworks (WANs). LANs typically connect the nodes over dedicated privatecommunications links located in the same general physical location, suchas a building or campus. WANs, on the other hand, typically connectgeographically dispersed nodes over long-distance communications links,such as common carrier telephone lines, optical lightpaths, synchronousoptical networks (SONET), synchronous digital hierarchy (SDH) links, orPowerline Communications (PLC) such as IEEE 61334, CPL G3, WPC andothers. In addition, a Mobile Ad-Hoc Network (MANET) is a type ofwireless ad-hoc network, which is generally considered aself-configuring network of mobile routes (and associated hosts)connected by wireless links, the union of which forms an arbitrarytopology.

Smart object networks, such as sensor networks in particular, are aspecific type of network consisting of spatially distributed autonomousdevices such as sensors that cooperatively monitor physical orenvironmental conditions at different locations, such as, e.g.,temperature, pressure, vibration, sound, radiation, motion, pollutants,etc. Other types of smart objects include actuators, e.g., objectsresponsible for turning on/off an engine or performing other actions.Sensor networks are typically wireless networks, though wiredconnections are also available. That is, in addition to one or moresensors, each sensor device (node) in a sensor network may generally beequipped with a radio transceiver or other communication port, amicrocontroller, and an energy source, such as a battery. Generally,size and cost constraints on sensor nodes result in correspondingconstraints on resources such as energy, memory, computational speed andbandwidth. Correspondingly, a reactive routing protocol may, though neednot, be used in place of a proactive routing protocol for sensornetworks.

In certain configurations, the sensors in a sensor network transmittheir data to one or more centralized or distributed database managementnodes that obtain the data for use with one or more associatedapplications. Alternatively (or in addition), certain sensor networksprovide for mechanisms by which an interested subscriber (e.g., “sink”)may specifically request data from devices in the network. In a “pushmode,” the sensors transmit their data to the sensor sink/subscriberwithout prompting, e.g., at a regular interval/frequency or in responseto external triggers. Conversely, in a “pull mode,” the sensor sink mayspecifically request that the sensors (e.g., specific sensors or allsensors) transmit their current data (or take a measurement, andtransmit that result) to the sensor sink. (Those skilled in the art willappreciate the benefits and shortcomings of each mode, and both apply tothe techniques described herein.)

With reference now FIG. 1, shown is a schematic block diagram of anexample computer network 100 illustratively comprising nodes/devices200, such as, e.g., routers, sensors, computers, etc., interconnected byvarious methods of communication (e.g., and labeled as shown, “LBR,”“11,” “12,” . . . “46”). For instance, the links of the computer networkmay be wired links or may comprise a wireless communication medium,where certain nodes 200 of the network may be in communication withother nodes 200, e.g., based on distance, signal strength, currentoperational status, location, etc. Those skilled in the art willunderstand that any number of nodes, devices, links, etc. may be used inthe computer network, and that the view shown herein is for simplicity.Illustratively, certain devices in the network may be more capable thanothers, such as those devices having larger memories, sustainablenon-battery power supplies, etc., versus those devices having minimalmemory, battery power, etc. For instance certain devices 200 may have noor limited memory capability. Also, one or more of the devices 200 maybe considered “root nodes/devices” (or root capable devices) while oneor more of the devices may also be considered “destinationnodes/devices.”

Data packet messages 142 (e.g., traffic and/or messages sent between thedevices/nodes) may be exchanged among the nodes/devices of the computernetwork 100 using predefined network communication protocols such as theTransmission Control Protocol/Internet Protocol (TCP/IP), User DatagramProtocol (UDP), Multi-Protocol Label Switching (MPLS), variousproprietary protocols, etc. In this context, a protocol consists of aset of rules defining how the nodes interact with each other. Inaddition, packets within the network 100 may be transmitted in adifferent manner depending upon device capabilities, such as sourcerouted packets.

FIG. 2 is a schematic block diagram of an example node/device 200 and aFAR device that may be used with one or more embodiments describedherein, e.g., as a root node or sensor. The device may comprise one ormore network interfaces 210, one or more sensor components 215 (e.g.,sensors, actuators, etc.), a power supply 260 (e.g., battery, plug-in,etc.), one or more processors 220 (e.g., 8-64 bit microcontrollers), anda memory 240 interconnected by a system bus 250. The networkinterface(s) 210 contain the mechanical, electrical, and signalingcircuitry for communicating data over physical and/or wireless linkscoupled to the network 100. The network interface(s) may be configuredto transmit and/or receive data using a variety of differentcommunication protocols, including, inter alia, TCP/IP, UDP, wirelessprotocols (e.g., IEEE Std. 802.15.4, WiFi, Bluetooth (Registeredtrademark), etc.,), Ethernet, powerline communication (PLC) protocols,etc.

The memory 240 comprises a plurality of storage locations that areaddressable by the processor(s) 220 and the network interface(s) 210 forstoring software programs and data structures associated with theembodiments described herein. As noted above, certain devices may havelimited memory or no memory (e.g., no memory for storage other than forprograms/processes operating on the device). The processor(s) 220 maycomprise necessary elements or logic adapted to execute the softwareprograms and manipulate the data structures, such as routes or prefixesof a routing/forwarding table 245 (notably on capable devices only). Anoperating system 242, portions of which are typically resident in memory240 and executed by the processor(s), functionally organizes the deviceby, inter alia, invoking operations in support of software processesand/or services executing on the device. These software processes and/orservices may comprise routing process/services 244, which may include anillustrative directed acyclic graph (DAG) process 246. Also, for rootdevices (or other management devices), a topology management process 248and associated stored topologies 249 may be present in memory 240, foruse as described herein. It will be apparent to those skilled in the artthat other processor and memory types, including variouscomputer-readable media, may be used to store and execute programinstructions pertaining to the techniques described herein. Also, whilethe description illustrates various processes, it is expresslycontemplated that the various processes may be embodied as modulesconfigured to operate in accordance with the techniques herein (e.g.,according to the functionality of a similar process).

Routing process (services) 244 contains computer executable instructionsexecuted by the processor(s) 220 to perform functions provided by one ormore routing protocols, such as proactive or reactive routing protocolsas will be understood by those skilled in the art. These functions may,on capable devices, be configured to manage routing/forwarding table 245containing, e.g., data used to make routing/forwarding decisions. Inparticular, in proactive routing, connectivity is discovered and knownprior to computing routes to any destination in the network, e.g., linkstate routing such as Open Shortest Path First (OSPF), orIntermediate-System-to-Intermediate-System (ISIS), or Optimized LinkState Routing (OLSR). Reactive routing, on the other hand, discoversneighbors (i.e., does not have an a priori knowledge of networktopology), and in response to a needed route to a destination, sends aroute request into the network to determine which neighboring node maybe used to reach the desired destination. Example reactive routingprotocols may comprise Ad-hoc On-demand Distance Vector (AODV), DynamicSource Routing (DSR), DYnamic MANET On-demand Routing (DYMO), etc.Notably, on devices not capable or configured to store routing entries,routing process 244 may consist solely of providing mechanisms necessaryfor source routing techniques. That is, for source routing, otherdevices in the network can direct the less capable devices exactly whereto send the packets, and the less capable devices simply forward thepackets as directed.

Low power and Lossy Networks (LLNs), e.g., certain sensor networks, maybe used in a myriad of applications such as for “Smart Grid” and “SmartCities.” A number of challenges in LLNs have been presented, such as:

1) Links are generally lossy, such that a Packet Delivery Rate/Ratio(PDR) can dramatically vary due to various sources of interferences,e.g., considerably affecting the bit error rate (BER);

2) Links are generally low bandwidth, such that control plane trafficmust generally be bounded and negligible compared to the low rate datatraffic;

3) A number of use cases require specifying a set of link and nodemetrics, some of them being dynamic, thus requiring specific smoothingfunctions to avoid routing instability, considerably draining bandwidthand energy;

4) Constraint-routing may be required by some applications, e.g., toestablish routing paths that avoid non-encrypted links, nodes runninglow on energy, etc.;

5) Scale of the networks may become very large, e.g., on the order ofseveral thousands to millions of nodes; and

6) Nodes may be constrained with a low memory, a reduced processingcapability, a low power supply (e.g., battery).

In other words, LLNs are a class of network in which both the routersand their interconnects are constrained; LLN routers typically operatewith constraints, e.g., processing power, memory, and/or energy(battery), and their interconnects are characterized by, illustratively,high loss rates, low data rates, and/or instability. The LLN may besized with devices ranging from a few dozen to as many as thousands oreven millions of LLN routers, and may support point-to-point traffic(between devices inside the LLN), point-to-multipoint traffic (from acentral control point to a subset of devices inside the LLN) andmultipoint-to-point traffic (from devices inside the LLN towards acentral control point).

An example protocol specified in an Internet Engineering Task Force(IETF) Pro-posed Standard, Request for Comment (RFC) 6550, entitled“RPL: IPv6 Routing Protocol for Low Power and Lossy Networks” by Winter,et al. (March 2012), provides a mechanism that supportsmultipoint-to-point (MP2P) traffic from devices inside the LLN towards acentral control point (e.g., LLN Border Routers (LBRs) or “rootnodes/devices” generally), as well as point-to-multipoint (P2MP) trafficfrom the central control point to the devices inside the LLN (and alsopoint-to-point, or “P2P” traffic). RPL (pronounced “ripple”) maygenerally be described as a distance vector routing protocol that buildsa Directed Acyclic Graph (DAG) for use in routing traffic/packets 140,in addition to defining a set of features to bound the control traffic,support repair, etc.

A DAG is a directed graph that represents a computer network, such ascomputer network 100, and that has the property that all edges areoriented in such a way that no cycles (loops) are supposed to exist. Alledges are contained in paths oriented toward and terminating at one ormore root nodes (e.g., “clusterheads or “sinks”), often to interconnectthe devices of the DAG with a larger infrastructure, such as theInternet, a wide area network, or other domain. In addition, aDestination Oriented DAG (DODAG) is a DAG rooted at a singledestination, i.e., at a single DAG root with no outgoing edges. A“parent” of a particular node within a DAG is an immediate successor ofthe particular node on a path towards the DAG root, such that the parenthas a lower “rank” than the particular node itself, where the rank of anode identifies the node's position with respect to a DAG root (e.g.,the farther away a node is from a root, the higher is the rank of thatnode). Further, a sibling of a node within a DAG may be defined as anyneighboring node which is located at the same rank within a DAG. Notethat siblings do not necessarily share a common parent, and routesbetween siblings are generally not part of a DAG since there is noforward progress (their rank is the same). Note also that a tree is akind of DAG, where each device/node in the DAG generally has one parentor, as used herein, one preferred parent.

DAGs may generally be built based on an Objective Function (OF). Therole of the Objective Function is generally to specify rules on how tobuild the DAG (e.g. number of parents, backup parents, etc.).

In addition, one or more metrics/constraints may be advertised by therouting protocol to optimize the DAG. Also, the routing protocol allowsfor including an optional set of constraints to compute a constrainedpath, such as where if a link or a node does not satisfy a requiredconstraint, it is “pruned” from the candidate list when computing thebest path. (Alternatively, the constraints and metrics may be separatedfrom the OF.) Additionally, the routing protocol may include a “goal”that defines a host or set of hosts, such as a host serving as a datacollection point, or a gateway providing connectivity to an externalinfrastructure, where a DAG's primary objective is to have the deviceswithin the DAG be able to reach the goal. In the case where a node isunable to comply with an objective function or does not understand orsupport the advertised metric, it may be configured to join a DAG as aleaf node. As used herein, the various metrics, constraints, policies,etc., are considered “DAG parameters.”

Illustratively, example metrics used to select paths (e.g., preferredparents) may comprise cost, delay, latency, bandwidth, estimatedtransmission count (ETX), etc., while example constraints that may beplaced on the route selection may comprise various reliabilitythresholds, restrictions on battery operation, multipath diversity, loadbalancing requirements, bandwidth requirements, transmission types(e.g., wired, wireless, etc.), and also a number of selected parents(e.g., single parent trees or multi-parent DAGs). Notably, an examplefor how routing metrics may be obtained may be found in an IETF InternetDraft, entitled “Routing Metrics used for Path Calculation in Low Powerand Lossy Networks”<draft-ietf-roll-routing-metrics> by Vas seur, et al.(Nov. 10, 2010 version). Further, an example OF (e.g., a default OF) maybe found in an IETF RFC, entitled “RPL Objective Function 0”<RFC 6552>by Thubert (March 2012 version).

Building of a DAG may utilize a discovery mechanism to build a logicalrepresentation of the network, and route dissemination to establishstate within the network so that routers know how to forward packetstoward their ultimate destinations. Note that a “router” refers to adevice that can forward as well as generate traffic, while a “host”refers to a device that can generate but does not forward traffic. Also,a “leaf” may be used to generally describe a non-router that isconnected to a DAG by one or more routers, but cannot itself forwardtraffic received on the DAG to another router on the DAG. Controlmessages may be transmitted among the devices within the network fordiscovery and route dissemination when building a DAG.

According to the illustrative RPL protocol, a DODAG Information Object(DIO) is a type of DAG discovery message that carries information thatallows a node to discover a RPL Instance, learn its configurationparameters, select a DODAG parent set, and maintain the upward routingtopology. In addition, a Destination Advertisement Object (DAO) is atype of DAG discovery reply message that conveys destination informationupwards along the DODAG so that a DODAG root (and other intermediatenodes) can provision downward routes. A DAO message includes prefixinformation to identify destinations, a capability to record routes insupport of source routing, and information to determine the freshness ofa particular advertisement. Notably, “upward” or “up” paths are routesthat lead in the direction from leaf nodes towards DAG roots, e.g.,following the orientation of the edges within the DAG. Conversely,“downward” or “down” paths are routes that lead in the direction fromDAG roots towards leaf nodes, e.g., generally going against theorientation of the edges within the DAG.

Generally, a DAG discovery request (e.g., DIO) message is transmittedfrom the root device(s) of the DAG downward toward the leaves, informingeach successive receiving device how to reach the root device (that is,from where the request is received is generally the direction of theroot). Accordingly, a DAG is created in the upward (UP) direction towardthe root device. The DAG discovery reply (e.g., DAO) may then bereturned from the leaves to the root device(s) (unless unnecessary, suchas for UP flows only), informing each successive receiving device in theother direction how to reach the leaves for downward routes. Nodes thatare capable of maintaining routing state may aggregate routes from DAOmessages that they receive before transmitting a DAO message. Nodes thatare not capable of maintaining routing state, however, may attach anext-hop parent address. The DAO message is then sent directly to theDODAG root which can, in turn, build the topology and locally computedownward routes to all nodes in the DODAG. Such nodes are then reachableusing source routing techniques over regions of the DAG that areincapable of storing downward routing state.

FIG. 3 illustrates an example DAO message 300 with a simplified controlmessage format that may be used for discovery and route disseminationwhen building a DAG, e.g., as a DIO or DAO. Message 300 illustrativelycomprises a header 310 having one or more fields 312 that identify thetype of message (e.g., a RPL control message) and a specific codeindicating the specific type of message, e.g., a DIO or a DAO (or a DAGInformation Solicitation). A body/payload 320 of the message maycomprise a plurality of fields used to relay pertinent information. Inparticular, the fields may comprise various flags/bits 321, a sequencenumber 322, a rank value 323, an instance ID 324, a (DO)DAG ID 325, andother fields, each as may be appreciated in more detail by those skilledin the art. Further, for DAO messages, fields for a destination prefix326 and a reverse route stack 327 may also be included. For either DIOsor DAOs, one or more additional sub-option fields 328 may be used tosupply additional or custom information (such as, e.g., the VGF) withinthe message 300. For instance, an objective code point (OCP) sub-optionfield may be used within a DIO to carry codes specifying a particularobjective function (OF) to be used for building the associated DAG.

Illustratively, the techniques described herein may be performed byhardware, software, and/or firmware, such as in accordance with thetopology management process 248, which may contain computer executableinstructions executed by the processor 220 (or independent processor ofinterfaces 210) to perform functions relating to the techniquesdescribed herein, e.g., in conjunction with routing process 244 (and/orDAG process 246). For example, the techniques herein may be treated asextensions to conventional protocols, such as the one or more routingprotocols (e.g., RPL) or other communication protocols, and as such, maybe processed by similar components understood in the art that executethose protocols, accordingly.

With the above generalized description provided above for LLNs and likenetworks, LLNs have several known problems (as mentioned above). Forinstance, and similar to other networks, LLNs can suffer from congestioncollapse when they attempt to service too much data traffic. In manycases, the effects of congestion collapse can be more acute for a numberof reasons. First, LLNs communicate using link technologies that providerelatively little link capacity yet forward traffic for hundreds orthousands of nodal devices. Second, the existence of LLN links are notknown by virtue of a physical connection. Instead, LLN devices discoverlinks to neighboring nodes and maintain an estimate of link qualityusing a variety of metrics (e.g. RSSI, LQI, and ETX). Congestion cancause link metrics to convey an inaccurate view of the link quality.Low-pass filters applied to such link metrics can reduce thereactiveness when congestion occurs, but also slows the recovery whencongestion subsides.

It is to be understood in many LLN applications, LLN devices typicallycommunicate with other devices outside the LLN. As a result, traffictypically flows through a Field Area Router (FAR) that connects the LLNto other IP-based networks. On one hand, since all LLN devices and theFAR have the same communication capabilities within the LLN, congestiontypically occurs at or near the FAR. On the other hand, the FAR alsoserves as a choke-point for the vast majority of LLN traffic flows andcan take advantage of that role to help avoid congestion collapse. Anexample of such a FAR is Cisco's 1000 Series Connected Grid Routers (CGR1000 Series) which are multi-service communication platforms configuredfor use in Field Area Networks (FANs). Such FARs provide consistentcommunications platforms for distribution and remote workforceautomation, and smart metering.

A FAR can maintain significantly more information about the network thanmost other LLN devices for a number of reasons. First, the FAR typicallyhas more computer processing and memory resources than the LLN devicesconnected to it. Second, because traffic typically flows through theFAR, the FAR has more visibility into the nature of the traffic in thenetwork. Third, routing protocols such as the Routing Protocol for LLNs(RPL) typically utilize the additional resources at the FAR to maintainrouting information. For example, with non-storing mode in RPL, the FARmaintains the entire Directed Acyclic Graph (DAG) topology.

It is also to be understood traffic shaping is a technique that delayssome or all datagrams to match a desired traffic profile. Trafficshaping is a form of rate limiting and is especially important innetworks that have limited resources (e.g., LLNs). A Traffic shaper isparameterized by a desired traffic profile and is often implementedusing leaky bucket or token bucket algorithms. A number of input/outputtraffic shaping techniques have been developed in the past for manytypes of link layers (e.g., ATM, FR, IP, etc.).

Thus, in view of the above, it will be understood from the belowdescription with reference to certain embodiments, aggregate throughputand efficiency of the LLN is significantly increased by dynamicallyadjusting the traffic shaping profile for data traffic admitted into aLLN. As noted above, an advantage of traffic shaping is avoidance ofknown issues caused by short or long-term congestion in LLNs. As will beappreciated from the below description, with knowledge of the routingtopology, a FAR can adjust the rate at which data packets are admittedinto the network based on the particular path that a packet musttraverse through the network. In differentiation from existing knowntraffic shaping techniques, the below described FAR actively adjusts thetraffic profile based on the routing topology. That is, the belowdescribed FAR is preferably configured and operative to dynamicallyadjust data packet traffic profiles used within a LLN based on theactual traffic and routing topology of the LLN.

It is to be appreciated shared communication media in LLNs (e.g., meshnetworks) differs from more traditional networks such (e.g. Ethernet andWiFi). In Ethernet networks, the physical media acts as a singlebroadcast domain where only a single device may transmit at a time andmultiple hops are segmented by distinct physical media that do notinterfere with each other. For instance, when forwarding a message in anEthernet network having a plurality of nodal devices, successive nodaldevices can transmit their respective messages to respective next hopssimultaneously. With regards to a WiFi network, the physical media ismore complex, and in contrast to Ethernet, the physical media is not asingle broadcast domain. Instead, typical WiFi deployments form a startopology, where multiple clients communicate directly with a singleaccess point. While the access point typically has a good view of thephysical media's activity, the client devices may not due to thewell-known hidden-terminal problem.

With returning reference to FIG. 1, multihop mesh networks (e.g., LLNs)take the physical media complexity a step further. In particular, therate at which a device can deliver messages depends on how many hops themessage must traverse. When the destination is only 1 hop away, thesource can transmit packets back-to-back since the destination willimmediately consume the message. However, when the destination is 2 hopsaway, the source must transmit packets at half the rate. For instance,when forwarding packets 144 and 146 from device LBR along the pathLBR→12→23, the first packet (144) goes from LBR→12 and then from 12→23.Note, however, that when the first packet (144) goes from 12→23, thesecond packet (146) which is to go from LBR→12 cannot transmit at thesame time since their respective messages (144, 146) would collide. Andwhen extending this example to three hops, the packet going from 12→23cannot transmit at the same time as the other packet going from LBR→12since they would collide at 12.

It is thus to be appreciated that when using a routing protocol such asRPL, the FAR has complete knowledge of the routing topology. In the caseof RPL with non-storing mode (the mode implemented in CG-Mesh), the FARknows the complete DAG topology. With this information, and as describedbelow, a FAR is able to dynamically adjust the parameters of a trafficshaper based on a packet's destination and the routing topology. Hencethe correlation between traffic shaping and routing topology. Since inthe below described embodiments the vast majority of traffic flowsthrough a FAR, the FAR is advantageously positioned for applying trafficshapers. Furthermore, a FAR is generally the source of congestion andprimarily utilizes knowledge of the routing topology within the firstfew hops to alleviate such congestion.

With reference now to the illustrated embodiment of FIG. 4 and theprocess 600 of FIG. 6, shown and described is a FAR device 410 coupledto a LLN 400 having nodal devices 420 to 448. In this embodiment, theFAR 410 is operational to perform downward forwarding of preferablyunicast data packet messages 450 that travel from the FAR 410 to adevice located in the LLN 400 using routing topology for the packetmessages 450 (step 610). For instance, in one embodiment, for eachpacket (e.g., 450) that the FAR 410 services, the FAR 410 is configuredand operational to determine if the destination is 1 hop, 2 hop, or 3+hops away in the LLN 400 (step 620). If it is determined it is 1 hopaway (e.g., 420), the FAR preferably does not delay (e.g., trafficshaping) any subsequent downward packets since the destination (420)will immediately consume the packet (450) and does not forward thepacket (450) to any other node. If it is determined the destination is 2hops away (e.g., 422), the FAR 410 delays a subsequent data packetmessage following transmission by the “expected time” (as discussedbelow) it takes for the packet to reach the two hop destination. If itis determined the destination is 3 or more hops away (e.g., 432) the FAR410 delays a subsequent data packet transmission by the expected time ittakes for the packet to reach such a multihop destination (432), whichmay or may not be the final destination for the data packet (step 630).It is noted this is particularly advantageous to single-channel networkswhere all devices communicate on a common channel. This is likewiseadvantageous in channel-hopping networks since there is some probabilitythat two nodes may utilize the same channel.

In one embodiment, the “expected time” is a function of the CarrierSense Multiple Access (CSMA) backoff, packet length, and bit rate. Inanother embodiment, the “expected time” may take into account the linkquality between nodal devices for the packet message path. For example,the estimated transmission count (ETX) provides an estimate on thenumber of transmissions it takes to communicate a message to itsdestination. Thus, the FAR (410) may scale the time delay by the ETXvalue. It is to be appreciated the above description classifies allpackets with a destination of 3 or more hops into the same bin. Inanother embodiment, the FAR (410) may add additional time delays basedon the number of hops and/or qualities of the links to reach thedestination. Longer paths are more likely to incur external interferenceand typically have larger variance in communication delays. A high ETX(i.e. poor) link more than three hops away can also cause packets tobackup at nodes closer to the FAR, causing higher queue occupancies andchannel contention. For these reasons, it is to be understood the FAR(410) may add additional delays based on the path length and linkqualities on the path, both of which affect the variance incommunication latency.

In accordance with another embodiment, the FAR (410) is operational andconfigured to adjust the traffic shaping delays based on how manyintermediate nodal hops are shared among the paths to differentdestinations. For example, if two paths (e.g., 420-422-430 and424-428-432) do not share any intermediate nodes (except for the FAR410), the FAR 410 is configured to transmit packets back-to-back byalternating between the paths. However, if two paths share all the sameintermediate nodes, the FAR 410 may preferably introduce traffic shapingdelays based on all of the considerations above. Note that in achannel-hopping system, the FAR 410 may consider that differenttransmitters can transmit simultaneously as long as they are ondifferent channels. For example, this knowledge affects whether or notthe FAR (410) must wait for a message to propagate 2 hops or 3 hopsbefore sending the next message.

With reference now to the illustrated embodiment of FIG. 5 and process700 of FIG. 7, shown and described is a FAR device 510 coupled to a LLN500 having nodal devices 520 to 548. In this embodiment, the FAR 510 isoperational to perform upward forwarding of preferably unicast datapacket messages 550 that travel to the FAR 510 from devices located inthe LLN 500 using routing topology for the packet messages 550 (step710). For instance, in one embodiment, the FAR 510 is configured andoperational to initially attempt to give each LLN device (520-538) anequal share of the network capacity to the FAR 510. It is to beunderstood a primary location of network congestion is typically locatedat the FAR 510 itself. Without knowledge of the routing topology, anaive approach would simply divide the FAR's (510) link capacity by thetotal number of nodes in the network 500. While this forms an initialbaseline, this naive approach does not consider that acknowledgmentframes sent from 1-hop nodes back to 2-hop nodes also collide with anytraffic sent to the FAR 510. Thus, in accordance with the illustratedembodiment, the FAR 510 is operational and configured to scale (e.g.,using traffic shaping techniques) the data packet traffic rate based onthe number of transmissions (550) that the FAR 510 expects to experiencefrom the LLN 500. In one such illustrative embodiment, the FAR 510divides the total channel capacity based on the number of 1-hop devicesand 2+ hop devices in the LLN (step 720). In particular, the FAR maydivide by (A+2*B) where A is the number of 1-hop devices and B is thenumber of 2 or more hop devices.

It is to be appreciated, and in contrast to the above describedillustrative embodiment of FIG. 5 concerning downward trafficking ofdata messages 550 from a FAR 510 to a LLN 500, the traffic shapers forupward trafficking of data messages 550 to a FAR 510 from a LLN 500 areimplemented on each LLN device (520-538) and are preferably applied todata packet messages that each LLN device sources (step 730). It is tobe understood the FAR 510 is operative and configured to communicate thenecessary information to each LLN device in a number of methods. Forinstance, in one embodiment, the FAR 510 communicates the number of1-hop and 2 or more hop devices to each LLN device (520-538). In anotherillustrative embodiment, the FAR 510 communicates the traffic profile toeach LLN device (520-538). In yet another illustrative embodiment, theFAR 510 communicates the information utilizing a RPL option in DIOmessages, an IEEE 802.15.4e Information Element in Enhanced Beacons, ora dedicated ICMPv6 Control message.

In still another illustrative embodiment, the FAR (510) is configuredand operational to dynamically adjust the amount of message capacityallocated to each node (520-538) based on the number of nodes, routingtopology, and the traffic activity in the LLN 500. For instance, aremote sub-DAG may have poor connectivity to the remaining portion ofthe network, and as a result, restricting all nodes to maintain the sametraffic rate does not utilize the full capacity of the entire network.Thus, the FAR 510 is configured and operational to determine that asubset of nodes can only utilize a portion of the network's capacitynear the root and thus allocates the available capacity to nodes thathave better connectivity.

With an above description of certain illustrative embodiments providedin regards to FAR downward and upward forwarding of unicast messages,description will be provided in regards to FAR forwarding of multicastdata packet messages. It is to understood multicast forwarding appliesto multicast packet messages that are forwarded by the FAR to an LLN. Itis also to be understood, in LLNs, multicast is typically implemented asa form of flood initiated by the FAR and may be implemented in differentways. For instance, Naive Flood involves having every node rebroadcastthe message at least once. Trickle Flood involves using a combination ofadaptive transmission timers with suppression so that the number oftransmissions scales with the log of node density. And Reduced-TopologyFlood involves forming a reduced topology (e.g. by discovering aConnected Dominating Set) and only having those nodes rebroadcast themessage.

In one illustrative embodiment, the FAR (410) models the time it takesfor a data packet message to propagate past the first few hops in a LLN(400) before the FAR (410) initiates a subsequent multicast data packettransmission. For example, with Naive Flood, the FAR (410) can computethe number of transmissions within the first 3 hops in the LLN (400) bydetermining the number of nodes within the first 3 hops. With regards toTrickle Flood, the FAR 410 is configured and operational to determinethe number of transmissions by taking the log of the nodes within thefirst 3 hops in the LLN (400). And with regards to Reduced-TopologyFlood, the FAR determines the number of nodes in the multicastforwarding topology that are within 3 hops of the FAR.

Hence, and in contrast to the above described the methods for forwardingunicast data packet messages, areas with high density away from the FAR(410) may also affect the multicast flood, thus performance of theaforesaid flooding techniques are preferably contingent on the densityof nodal devices. For instance, in the scenario where the LLN (400) inproximity to the FAR (410) is sparse but is relatively dense in a patchof nodal devices that is several hops away from the FAR 410, themulticast propagation rate is preferably limited by the dense patchitself. It is to be understood, unicast messages are typically notaffected by such densities since each unicast message only causes a fewtransmissions within a given cell.

In another illustrative embodiment for multicast messages, the FAR (410)is operational and configured to model the time it takes to propagatethe multicast message throughout the entire LLN (400) based upon theFAR's (410) knowledge of the routing topology. For example, for bothNaive and Trickle Floods, the FAR (410) may search for the patch ofnetwork that is most dense, and compute the number of transmissions areexpected for each multicast message. The FAR (410) then scales themulticast forwarding rate accordingly.

In view of the above described description for certain illustratedembodiments, it is to be now appreciated a FAR device (410) according tothese embodiments is operational and configured to effectively computethe available capacity based on the routing topology of an LLN and amessage packet's destination to ensure that the traffic rate does notexceed capacity. In addition to the packet's destination, the FAR mayclassify traffic and utilize capacity according to the traffic class. Itis to be appreciated and understood, any existing mechanism to classifytraffic may be utilized (e.g. IPv6 Traffic Class, DPI, etc.). Thus,implementing the above described embodiments with traffic classificationenables policies that allocate a capacity percentage to each trafficclass. It is to be appreciated, existing mechanisms typically assume afixed capacity (e.g. based on the link's physical data rate). Forexample, some policies are specified by absolute data rates (e.g. kbps).Other policies based on percentage are often implemented assuming afixed data rate. However, when utilizing the above describedembodiments, and since a network's actual capacity depends on therouting topology and packet destination, the FAR (410) is now configuredand operational to inject packets by also dynamically computing how muchcapacity may be given to a particular traffic class. In one suchembodiment, the FAR (400) computes the delay for maximum throughput andscales that by the percentage given in the policy configuration.

Accordingly, with certain illustrative embodiments described above, whathas been described in one aspect is the utilization of routing topologyinformation to actively adjust a traffic shaper policy for data packetsin a LLN. That is, a traffic profile is actively determined based on thepath a data packet travels and the LLN routing topology. In regards tounicast messages, the FAR considers the length of the path, and in someinstances, the link qualities along the path and the traffic activity.With regards to multicast messages, the FAR determines the expected timeto propagate the message through the most dense portion(s) of the LLN.

Thus, an advantage provided is optimization of the aggregate throughputand efficiency of an LLN by ensuring that channel utilization in the LLNoperates efficiently. By intelligently adjusting traffic shapingbehavior, a FAR device actively mitigates the occurrence of congestionand its negative side effects (e.g., skewed link quality estimates,routing instability, etc.). Hence, by utilizing information with thedata packet and the routing topology known to a FAR, no additionalcontrol messages are required to monitor the state of the network.

It is to be appreciated that while certain steps within procedures 600and 700 may be optional as described above, the steps shown in FIGS. 6and 7 are merely examples for illustration, and certain other steps maybe included or excluded as desired. Further, while a particular order ofthe steps is shown, this ordering is merely illustrative, and anysuitable arrangement of the steps may be utilized without departing fromthe scope of the embodiments herein.

While there have been shown and described illustrative embodiments thatprovide for traffic shaping by a FAR device, it is to be understood thatvarious other adaptations and modifications may be made within thespirit and scope of the embodiments herein. For example, the embodimentshave been shown and described herein with relation to LLN networks, and,in particular, the RPL protocol. However, the embodiments in theirbroader sense are not as limited, and may, in fact, be used with othertypes of networks and/or protocols.

The foregoing description has been directed to specific illustratedembodiments. It will be apparent, however, that other variations andmodifications may be made to the described embodiments, with theattainment of some or all of their advantages. For instance, it isexpressly contemplated that the components and/or elements describedherein can be implemented as software being stored on a tangible(non-transitory) computer-readable medium (e.g.,disks/CDs/RAM/EEPROM/etc.) having program instructions executing on acomputer, hardware, firmware, or a combination thereof. Accordingly thisdescription is to be taken only by way of example and not to otherwiselimit the scope of the embodiments herein. Therefore, it is the objectof the appended claims to cover all such variations and modifications ascome within the true spirit and scope of the embodiments herein.

What is claimed is:
 1. A method, comprising: receiving, at a Field AreaRouter (FAR) device, data packet messages sent from one or more sourcestoward one or more destination devices in a Low-Power Lossy Network(LLN), wherein the FAR is a root node for the LLN; in response toreceiving the data packet, interpolating, in the FAR, LLN routingtopology for the data packet messages by at least determining whether adestination device of the data packet message is more than a prescribednumber of hops away from the FAR; in response to interpolating,determining an expected time for the data packet messages to reach adestination device in the LLN based upon the routing topologyinterpolation; and applying traffic shaping by the FAR for the datapacket messages based upon the determined expected time for the datapacket messages to reach destination devices in the LLN.
 2. The methodas recited in claim 1, wherein the data packet messages are received inthe FAR from non-LLN sources.
 3. The method as recited in claim 1,wherein the applying traffic shaping step includes delaying transmissionof the data packet messages in the LLN.
 4. The method as recited inclaim 1, wherein the determining an expected time step includesdetermining a number of nodal hops data packet messages travel to reachdestination devices in the LLN.
 5. The method as recited in claim 1,wherein the determining an expected time step is a function of CarrierSense Multiple Access (CSMA) backoff, packet length and bit rateregarding transmission of data packet messages in the LLN.
 6. The methodas recited in claim 1, wherein the determining an expected time stepincludes determining the quality of nodal links data packet messageswill travel across to reach destination devices in the LLN.
 7. Themethod as recited in claim 6, wherein determining an expected time fordata packet messages to reach destination devices is a function of botha determined nodal path length and the determined quality of nodal linksdata packet messages will travel across to reach destination devices inthe LLN.
 8. The method as recited in claim 1, wherein the determining anexpected time step includes determining a number of intermediate nodalhops that are shared by various nodal paths to various destinationdevices in the LLN.
 9. A method, comprising: receiving, at a Field AreaRouter (FAR), multicast data packet messages to be forwarded to aLow-Power Lossy Network (LLN), wherein the FAR is a root node for theLLN; in response to receiving, interpolating, in the FAR, a LLN routingtopology for the received multicast data packet messages; and inresponse to interpolating, applying traffic shaping by the FAR for themulticast data packet messages by modeling the time it takes for a datapacket message to propagate across a prescribed amount of nodal hops inthe LLN prior to the FAR initiating subsequent transmission of multicastdata packet messages in the LLN.
 10. The method as in claim 9, whereinthe time modeling step includes use of one of: naive flood, trickleflood or reduced-topology flood data packet message routing techniques.11. The method as recited in claim 9, wherein the time modeling stepincludes the FAR modeling a time it takes to propagate the multicastdata packet message in the LLN without reliance on the LLN mutingtopology.
 12. The method as recited in claim 9, wherein the applyingtraffic shaping step includes delaying transmission of the data packetmessages in the LLN.
 13. An apparatus, comprising: one or more networkinterfaces configured to communicate with a Low Power and Lossy Network(LLN); a processor coupled to the interfaces and adapted to execute oneor more processes; and a memory configured to store a Field Area Routerprocess executable by the processor, the process when executed operableto: receive data packet messages sent from one or more sources intendedfor transmission toward one or more destination devices in the LLN),wherein the FAR is a root node for the LLN; in response to the datapacket being received, interpolate LLN routing topology for the datapacket messages by at least determining whether a destination device ofthe data packet message is more than a prescribed number of hops awayfrom the FAR; in response to interpolation, determine an expected timefor the data packet messages to reach a destination device in the LLNbased upon the routing topology interpolation; and apply traffic shapingfor the data packet messages based upon the determined expected time fordata packet messages to reach destination devices in the LLN.
 14. Theapparatus as recited in claim 13, wherein the applying traffic shapingstep includes delaying transmission of the data packet messages in theLLN.
 15. The apparatus as recited in claim 13, wherein the determinationof an expected time includes determining a number of nodal hops for datapacket messages to reach destination devices in the LLN.
 16. Theapparatus as recited in claim 13, wherein the application of trafficshaping includes delaying transmission of the data packet messages inthe LLN.
 17. The apparatus as recited in claim 13, wherein thedetermination of the expected time is a function of Carrier SenseMultiple Access (CSMA) backoff, packet length and bit rate regardingtransmission of data packet messages in the LLN.
 18. The apparatus asrecited in claim 13, wherein the determination of the expected timeincludes determining the quality of nodal links data packet messageswill travel across to reach destination devices in the LLN.
 19. Theapparatus as recited in claim 18, wherein the determination of theexpected time for data packet messages to reach destination devices is afunction of both a determined nodal path length and the determinedquality of nodal links data packet messages will travel across to reachdestination devices in the LLN.
 20. An apparatus as recited in claim 13,wherein the determination of the expected time includes determining anumber of intermediate nodal hops that are shared by various nodal pathsto various destination devices in the LLN.